home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 768 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.8 KB
  1. From: Mark.Baker@mettav.exnet.com (Mark Baker)
  2. Date: 12 Jul 94  21:04:50
  3. Message-Id: <UUCP.774153288@mettav>
  4. Subject: Digest
  5. To: gem-list@world.std.com (gem-list@world.std.com)
  6. Precedence: bulk
  7.  
  8. Rainer:
  9.  > I wish I could remember (because I have no Atari-keyboard anymore). I
  10.  > think it was {} for example on a German keyboard. To get them you have to
  11.  
  12. That's a bit awkward for C programming :)
  13.  
  14.  > press 'Cntrl Alt Umlaut-O/A' (?!). Here on my PC-like keyboard I have
  15.  > another ALT- key named 'Alt Gr' to get the third level of multipurpose
  16.  
  17. I wondered what alt-gr was for :) It does nothing on UK PC keyboards.
  18.  
  19. Ken:
  20.  > You have to understand how GEM works before you can bring up an argument
  21.  > like this. The fact is that not every application will get a mouse event
  22.  > unless they write their own mouse routine (not everyone is willing to do :-
  23.  
  24. But surely your proposal is that everyone will have to to implement your
  25. standard? It's not a problem now but if you make it mandatory you will have all
  26. programs doing it, which slows it down.
  27.  
  28.  > There is another problem here -- our library allows you to set multiple
  29.  > timer events and 'attach' them to windows. If we set our event_timer to
  30.  > wait for rectangle events, then the timers would become effectively
  31.  > useless. The library does need to do events on a regular basis, but only
  32.  > mouse events will be done if the application is TOPPED.
  33.  
  34. What does using mouse rectangle events have to do with whether you receive
  35. timer events anyway?
  36.  
  37.  > Extended object types can *easily* handle behavioural objects. Just look
  38.  > at WinLIB PRO's active sliders. Those are just normal everyday sliders,
  39.  > with the one addition that their extended object type is different.
  40.  >
  41.  > You're saying that with Gem++ you would have to add code to support the
  42.  > active slider, perhaps doing something like "register_active_slider(TREE,
  43.  > object, orientation);" which is insane. Having to write code to support
  44.  > an interface when the interface should do those things ITSELF is a pain.
  45.  
  46. But you need to attach code to the active slider anyway, or any other type of
  47. object. For example you might have a check-box object which is handled
  48. automatically, but you still have to specify the code for it, perhaps in a
  49. switch statement. In GEM++ you just declare that the existing button should be
  50. a check-box of a particular application specific class, and it changes the
  51. behaviour and appearance.
  52.  
  53.  > Besides the fact that if you want to change the functionality of a button,
  54.  > you can't do it visually, you have to do it programatically. This is
  55.  > right along the lines of insanity that MultiTOS did when they forced you to
  56.  > do heirarchical menus by linking them together within your code, rather
  57.  > than the *obvious* way of allowing you to design heirarchical menus using
  58.  > a resource editor.
  59.  
  60. You can still edit them in a resource editor. From your code you declare an
  61. object and this attaches code to them and may optionally change the appearance.
  62. You cannot do it from a resource editor because there are an infinite number of
  63. different types of code that may be attached.
  64.  
  65.  > To me, this seems like an *ENORMOUS* disadvantage of Gem++, as it is with
  66.  > MultiTOS. A library is supposed to make coding easier, not more
  67.  > difficult.
  68.  > Is it any wonder why nobody has used Gem++ for anything yet? :-)
  69.  
  70. Have you used GEM++? Were there a decent fast c++ compiler for the Atari I
  71. would use it all the time.
  72.  
  73. [wind_update for dialogues]
  74.  > May not be necessary, but it's desired.  Remember, you're trying to keep
  75.  > the program as compatible as possible.  If you don't use wind_update,
  76.  > then when you move your mouse to the menu-bar, the program will lock up,
  77.  > guaranteed.
  78.  
  79. Without MultiTOS (or presumably MagiC etc) dialogue boxes do not need
  80. wind_update, although Atari recommend it it makes very little difference as the
  81. form_do handler includes a wind_update call anyway.
  82.  
  83.  
  84.  
  85.